Red Hat cutting back RHEL source availability [LWN.net]

Red Hat cutting back RHEL source availability

Posted Jun 21, 2023 16:34 UTC (Wed) by ju3Ceemi (subscriber, #102464) [Link] (1 responses)

Yes
And those 3rd party are supported on redhat -not on some clones like centos.

So if you care about being supported, you pay and use redhat
If you are not, then you could as well use anything else: suse, Debian, gentoo, whatever

Red Hat cutting back RHEL source availability

Posted Jun 22, 2023 4:34 UTC (Thu) by mbar (guest, #73813) [Link]

> not on some clones like centos
You just wrote that Debian testing is a clone of Debian stable.

Red Hat cutting back RHEL source availability

Posted Jun 21, 2023 17:49 UTC (Wed) by jzb (editor, #7867) [Link] (21 responses)

"It is not that Red Hat is providing some particularly sophisticated solution no one else could have come up with."

This seriously undervalues what Red Hat does overall with RHEL. Red Hat didn't start out in a "uniquely strong" postion, they fought to get there. Providing a "supported environment for 3rd party software" is a lot more complex and sophisticated than people give Red Hat credit for -- Red Hat has to do a ton of development work upstream to land features that customers want across multiple upstreams.

Then they work with partners to do testing and certification. And then they support an operating system for a decade plus, including upstreams that go EOL like Python 2.7.

Red Hat makes open source consumable and boring for businesses. It's a lot of chopping wood and carrying water that competitors have tried very very hard to avoid, in a variety of ways. (Credit where due, I think SUSE tries to emulate this to a large degree, they've just been less successful at scaling it.)

Just because Alma and Rocky and others can quickly recompile the source code to RHEL should in no way delude people to think they can easily step in and do all the development that happens up to that point. People seem to handwave away all the work that leads up to that source code in the first place. Sophisticated isn't really the metric here: it's the ability to deliver an open source platform that's consumable by business at scale for a decade. Repeatedly.

But people have seriously devalued that because they can get the bits for free without thinking too much about all the work that went into the source that makes the bits available.

There's a related discussion about how relevant RHEL is now given that the world is moving away from a model of staying on an OS for 10 years. But that doesn't decrease the complexity of providing that or make it any more honest to handwave away what RHEL represents as not "particularly sophisticated."

Disclaimer: I'm a former Red Hat employee (and even more former SUSE/Novell employee...)

Red Hat cutting back RHEL source availability

Posted Jun 21, 2023 18:35 UTC (Wed) by pizza (subscriber, #46) [Link]

> Just because Alma and Rocky and others can quickly recompile the source code to RHEL should in no way delude people to think they can easily step in and do all the development that happens up to that point. People seem to handwave away all the work that leads up to that source code in the first place. Sophisticated isn't really the metric here: it's the ability to deliver an open source platform that's consumable by business at scale for a decade. Repeatedly.

Yeah. It's all very cargo-cult-ish.

Red Hat cutting back RHEL source availability

Posted Jun 21, 2023 18:59 UTC (Wed) by ju3Ceemi (subscriber, #102464) [Link] (18 responses)

10 year-plus
This is so damageable to the world

This kind of offer helps the damaged mindset from the 90ise that you can, sanely, let an environment live forever

Red Hat cutting back RHEL source availability

Posted Jun 21, 2023 20:03 UTC (Wed) by pbonzini (subscriber, #60935) [Link] (12 responses)

> 10 year-plus This is so damageable to the world

Yet I guess you complain about planned obsolescence and lack of firmware update when it's about phones, TVs or NAS enclosures...

Red Hat cutting back RHEL source availability

Posted Jun 21, 2023 20:09 UTC (Wed) by ju3Ceemi (subscriber, #102464) [Link] (11 responses)

Hardware is not software

In which sane world do you run a ten-year old libssl ?
In which sane world do you use a ten-year old screen ?

I have différent answer for those questions

Red Hat cutting back RHEL source availability

Posted Jun 21, 2023 20:17 UTC (Wed) by pgarciaq (subscriber, #153687) [Link] (5 responses)

In which sane world do you run a ten-year old libssl? In which sane world do you use a ten-year old screen?

In essentially any enterprise environment, actually.

Red Hat cutting back RHEL source availability

Posted Jun 21, 2023 20:21 UTC (Wed) by ju3Ceemi (subscriber, #102464) [Link] (4 responses)

Those same environnement that closes for two month after a cyberattack ?
I don't know, I've work for many compagnies and never met such choices with succesful outcome: it was always a failure

Red Hat cutting back RHEL source availability

Posted Jun 22, 2023 18:54 UTC (Thu) by clump (subscriber, #27801) [Link] (2 responses)

Distributions like RHEL and Debian may ship older versions of software. When security issues arise, maintainers may backport fixes or upgrade to newer versions.

More information for RHEL can be found here: https://access.redhat.com/security/updates/backporting

Red Hat cutting back RHEL source availability

Posted Jun 22, 2023 19:19 UTC (Thu) by ju3Ceemi (subscriber, #102464) [Link] (1 responses)

Yes, yes, that's a nice story

On the other hand, let's have this other nice story
You have rhel 6, supported up to 2020, released in 2010 with openssl 1.0.0

TLS 1.2 has been added to openssl 1.0.1 in 2012

Question: in 2020, on my fully supported rhel 6 server, do I:
- use TLS 1.1, because that's all I can get and I am insecure
- use TLS 1.2, because redhat backported the whole TLS 1.2 implementation

Answer:
None
openssl was upgraded from 1.0.0 to 1.0.1 somewhen

So you started with a specific version, and upgraded to another
Basically, you could've just upgraded to the next release ..
Yes, I know that this "is just a library"

Yet if you have a very sensitive system, upgrading just that library means running the full qualification procedure

Anyway
From my personnal experience in compagnies, 10-years support is very great because people can just fire some stuff and move on
Said stuff will rot in place, never to be touch in many years, but that is not my problem so I do not care
And then you come, consider said system, consider that everybody who worked with that thing left years ago
And you cry alone in the dark

3-years support is far better from a security perspective, because it is a reason to keep taking care of stuff: manager will give you time, security teams will prioritize etc
And when systems are kept sane all the time, as when you clean your house, so job is simple and easy
Whereas when you leave the dirt for year, good luck cleaning the mess ...

Security is nothing but psychology.

Red Hat cutting back RHEL source availability

Posted Jun 22, 2023 20:37 UTC (Thu) by clump (subscriber, #27801) [Link]

OpenSSL is a good example of what we're talking about. The answer to your question is to update the package and TLS version. See: https://access.redhat.com/articles/1462223

Ten+ year security doesn't make software less secure, quite the opposite. You can still upgrade to a new version of RHEL every two or three years. My experience is that organizations don't care as much about operating system versions as they do about the versions of the applications and languages they're running. In those cases, they're often providing their own OpenSSL or Java or Python.You might upgrade the OS every couple of years, but you're constantly upgrading your applications.

Too many of my customers *only* care about their applications. They don't think much about the underlying operating system. That's among my customers that self-manage. Many of my customers are running toward cloud services as fast as possible.

Red Hat cutting back RHEL source availability

Posted Jun 23, 2023 13:40 UTC (Fri) by Freecoffee (guest, #165758) [Link]

From the security perspective new is not always better, and the work RHEL does is epic at this point.

There was a time in computing when everything could be free/semi free and open but all that leads to now is lack of viability and longevity of the work.

If anyone has not noticed the billion hours of coding in flash sites that evaporated from the internet.

I have worked in development for companies and the honest truth is no one can afford to direct resources to perfection and recreating the wheel.
Yes ivey grows over entire areas of apps and buisness processes and in a perfect world there would be maintenance but that is not any company I have ever worked for.

On a side note the cloud is great until you need to have stable costs. It does not give an operation a lot of leverage in negotiation when you are dependant on the cloud for your buisness infrastructure. No asset model what could go wrong.

Red Hat cutting back RHEL source availability

Posted Jun 21, 2023 20:33 UTC (Wed) by pbonzini (subscriber, #60935) [Link] (1 responses)

Lack of updates is a huge part of how you get planned obsolescence.

I have a Synology NAS from 2013 that got its last *major* update last year, and it's not even cloud enabled. Meanwhile other companies that actually expose your data on the internet might sell you an old model that they don't plan to update anymore in 2025.

Well, Synology is doing the same kind of work as Red Hat.

Red Hat cutting back RHEL source availability

Posted Jun 22, 2023 4:07 UTC (Thu) by mathstuf (subscriber, #69389) [Link]

I just retired by 10-year-old Synology today actually. Alas, with WFH, doing `rclone` over VPN to the cloud was a losing proposition and Golang has yet to support the MIPS32 processor it used, so my remote backups have been out-of-date for quite a while. It had a good run, but the hardware choices never got adopted by the New Languages :/ .

Red Hat cutting back RHEL source availability

Posted Jun 22, 2023 0:05 UTC (Thu) by butlerm (subscriber, #13312) [Link] (2 responses)

The entire business model of a company like Red Hat requires making critical and necessary updates to versions of dependencies long since abandoned by their original developers. In other words no one using RHEL is running an unpatched, unsecured ten year old libssl or anything like it, they are using a generally ABI compatible version maintained by Red Hat with security fixes and necessary upgrades, and often more than one such version.

Red Hat cutting back RHEL source availability

Posted Jun 23, 2023 7:06 UTC (Fri) by taladar (subscriber, #68407) [Link] (1 responses)

So really, when you think about it, they are running bleeding edge software versions that got limited testing, patched by people who know less about it than the original developer. But because said developer chose not to modify the version number people think their system is somehow "stable".

Red Hat cutting back RHEL source availability

Posted Jun 23, 2023 16:14 UTC (Fri) by jzb (editor, #7867) [Link]

"So really, when you think about it, they are running bleeding edge software versions that got limited testing, patched by people who know less about it than the original developer."

Really, when I think about it, I am aware of the amount of testing that goes into RHEL and feel fairly confident that if what I need is a long-term stable operating system it's going to meet my needs.

The original developer / project, in many cases, hasn't done nearly the amount of testing against what they've released vs. what ends up in RHEL. Calling it "bleeding edge" is silly. The reason many people want and pay for RHEL is because they know that there's additional testing vs. the vanilla upstream.

I would grant you that the original developer has more context for the original software. Whether they know more than the person patching it, overall, is not guaranteed. Whether they're better at security or fixing security issues is definitely up for debate.

You seem to be simultaneously arguing that you really want to run RHEL, and that it has little value, which is mystifying to me.

Red Hat cutting back RHEL source availability

Posted Jun 24, 2023 15:13 UTC (Sat) by wtarreau (subscriber, #51152) [Link] (4 responses)

> 10 year-plus
> This is so damageable to the world
> This kind of offer helps the damaged mindset from the 90ise that you can, sanely, let an environment live forever

Yeah for sure... Quite frankly, read what you wrote, all of this makes zero sense. You're taking the example of people that do not apply any single update to judge a model where a vendor makes the effort of providing updates so that responsible customers can maintain their software up to date.

For sure some people like those making a living of selling hardware might prefer to see landfills full of obsolete cars because the software that runs on the central computer isn't supported anymore, make a business of desoldering components from obsoleted smartphones, or doubling the price of energy delivered to a vulnerable neighbor country while they're running maintenance operations to replace the hardware in power plants due to the new requirements of a major software upgrade. But there are also a lot of people who want to keep safe software running fine on existing hardware without changing prerequisites every 3 years nor facing regressions due to forced major upgrades.

You seem to be ignoring an important fact, which is that a linux distro is primarily a redistribution of a collection of opensource software, and that a lot of them are done as side jobs, and not in a professional manner, meaning that forward compatibility is not the most common thing. As such performing a distro upgrade almost guarantees a number of regressions or breakages that are sometimes OK on your laptop but not at all in many environments. Distro vendors providing 10 years support go through that effort mainly to protect their customers from this.

Red Hat cutting back RHEL source availability

Posted Jun 24, 2023 15:40 UTC (Sat) by ju3Ceemi (subscriber, #102464) [Link] (3 responses)

Excuse me .. what ?

I am sitting on a i5-2400, released in 2011, running Debian 12 (released in 2023)
Do you really believe people have to change hardware every time they update the software ?

That is .. that is crazy

Also, when you pay a RHEL subscription for a server (at least 350$/y without support nor any stuff), you probably have some kind of business behind this
People with hobbies for their free time do not pay that money for the elusive right to use old hardware ..

Red Hat cutting back RHEL source availability

Posted Jun 25, 2023 8:13 UTC (Sun) by wtarreau (subscriber, #51152) [Link] (2 responses)

The 'E' of RHEL stands for "Enterprise". Nobody cares about your i5-2400 released in 2011 in this context, as it's not supposed to run this distro. And yes, most enterprise users will renew their hardware after a few years to save on energy costs. The fact that your 4-core 95W i5-2400 from 2011 is half as powerful as a 8-core 7W Core i3-N300 from 2023 is probably not a problem for you, but it's an enterprise's responsibility to divide power usage per performance unit by 27 like this over the years. Thus in practice a server will be installed with a distro and will run it until it gets decommissioned 3-8 years later. And that's also in this context that for such users the effort made by package maintainers to provide non-breaking updates that fix bugs and security issues is valued, because these customers basically don't have to think about the software anymore. On your PC or laptop you can devote time adjusting/fixing packages after an upgrade if you want. When you deal with 1000 servers you don't want to discover breakage every morning anymore.

I, too, used to find CentOS interesting for end users. It's just that lots of consultants install this at their customers' as a way to save money by not buying the original, hence avoiding to pay for the development effort done upfront. I'm not seeing a simple solution to this, to be honest. Maybe they should make a free version of RHEL which is trivial to activate and switch to a paid mode, to try lower the barrier of adoption, and pre-fill a number of visible config files with "this is an unregistered copy, if you value it please consider supporting our effort". But the constant guerilla between RHEL and forks is only hurting their users, community and their image by making the solution look not sustainable in my opinion.

Red Hat cutting back RHEL source availability

Posted Jun 25, 2023 8:23 UTC (Sun) by ju3Ceemi (subscriber, #102464) [Link] (1 responses)

So enterprise will renew their hardware to save energy
Nothing related to RHEL

Mais tu sais, je me suis déjà occupé d'un parc de 3500 serveurs (à l'époque où j'étais ton client)
Peut-être n'avons-nous pas eu les mêmes expériences professionnelles, fréquentés les mêmes genre d'entreprise ?

Thank you for your feedback anyway

Red Hat cutting back RHEL source availability

Posted Jun 26, 2023 4:50 UTC (Mon) by wtarreau (subscriber, #51152) [Link]

Maybe, maybe not, I can't know since you're posting under an alias. In any case if you've dealt with so many servers you certainly understand the value of not going through major upgrades for no reason and only applying the regular fixes that come with enterprise distros.

Red Hat cutting back RHEL source availability

Posted Jun 21, 2023 21:22 UTC (Wed) by Wol (subscriber, #4433) [Link]

> Red Hat makes open source consumable and boring for businesses. It's a lot of chopping wood and carrying water that competitors have tried very very hard to avoid, in a variety of ways. (Credit where due, I think SUSE tries to emulate this to a large degree, they've just been less successful at scaling it.)

To put it another way, it's Red Hat that puts food on the programmers' tables.

Cheers,
Wol

Red Hat cutting back RHEL source availability

Posted Jun 22, 2023 18:19 UTC (Thu) by markhahn (subscriber, #32393) [Link] (4 responses)

debatable - rh is a flag of convenience.

but think about what the vendors are doing here: it's slimy. they should be saying "our app runs on anything compliant with a particular standard". the whole "supported on" is lazy and hostile to the customer.

Red Hat cutting back RHEL source availability

Posted Jun 22, 2023 22:48 UTC (Thu) by farnz (subscriber, #17727) [Link] (1 responses)

It's not so much slimy, as lazy (in the sense that all programmers are lazy). If I say "runs on anything compliant with a particular standard", then I need some way of verifying that my app really does run on anything compliant with that standard - that means that tools need to exist that check my app for cases where it assumes an implementation detail, and tools need to exist to verify compliance of your OS with the standard.

By saying "runs on Ubuntu 14.04 LTS", I've isolated down exactly what I'm promising - if I accidentally depend on an implementation detail of Ubuntu 14.04 LTS that changed in 16.04, that's fine, because I promised I'd work with 14.04 LTS only. And if Canonical update Ubuntu 14.04 LTS and break my app, I've got to catch up; so I want to work with Canonical to ensure that either this doesn't happen, or I have some notice and can fix my app before my customers get the update.

Same logic applies to RHEL, except that the RHEL support lifetimes are slightly longer than Ubuntu LTS (6 years to last release instead of 5, 12+ years from first release to end of ELS to Ubuntu's 10 years from first release to end of ESM).

Red Hat cutting back RHEL source availability

Posted Jun 23, 2023 0:48 UTC (Fri) by intelfx (subscriber, #130118) [Link]

> By saying "runs on Ubuntu 14.04 LTS", I've isolated down exactly what I'm promising - if I accidentally depend on an implementation detail of Ubuntu 14.04 LTS that changed in 16.04, that's fine, because I promised I'd work with 14.04 LTS only.

Well, that’s exactly what OP meant by “[being] hostile to the customer”.

Red Hat cutting back RHEL source availability

Posted Jun 23, 2023 8:53 UTC (Fri) by eduperez (guest, #11232) [Link]

> they should be saying "our app runs on anything compliant with a particular standard".

History has told us, over and over again, that being "compliant" with a particular standard, means next to nothing; there are countless "anecdotes" of software compliant in theory, but incompatible in practice.

Red Hat cutting back RHEL source availability

Posted Jun 23, 2023 16:31 UTC (Fri) by jzb (editor, #7867) [Link]

Have you supported any products of note against "anything compliant with a particular standard" yourself?

What the vendors are doing is not slimy, lazy, or hostile here. First of all, the idea that there even exists a "particular standard" to be compliant *with* is questionable given the number of dependencies that any given application might have. What standards would you suggest that are adequate to say that a database or streaming/messaging platform is supported?

Let's say I want to ship a product based on Apache Kafka. Please tell me which standards I can target that are available in shipping operating systems that guarantee if I target them I can also promise support.

The most reasonable way for a vendor to develop, test, and support an enterprise type application is to pick specific versions of popular operating systems and work against those. Because we're not just talking about "it compiles and runs" -- we're talking about being able to support a customer with heavy workloads and a contract with an SLA that says downtime costs you, the vendor, money.