[qalmakka]

This is why I've always disliked Debian and Red Hat.

1. I hate the fact they have the hubris to think they can be smarter than the upstream developers and patch old versions

2. I hate the fact they don't ship vanilla packages, but instead insist on patching things for features that nobody relies on anyway, __because they're not upstream__.

Maintainers should stick to downloading tarballs, building them and updating them promptly when a new version is out. If there's no LTS available, pay upstream and get an LTS, don't take a random version and patch it forever just to keep the same version numbers, it's nonsensical and it was only a matter of time before people tried to exploit it. Just look at the XZ backdoor for instance, which relied on RedHat and Debian deploying a patched libsystemd.

[gruturo]

Enterprises don't go for RHEL because it's free software, yay freedom!

They go for it because it gives a very stable, solid foundation. They don't want a fragile base layer prone to breaking every day of the week.

This involves backporting a lot of stuff (primarily security fixes) because you can't just upgrade any package to its latest version, it will have entirely new dependencies, potentially breaking changes etc.

What should RedHat do, which does not:

1) make them lose their enterprise customers wanting a stable base

2) have unpatched security holes all over their distros

3) not cause them to backport stuff (we are here at the moment) ?

[JackSlateur]

Compagnies I've worked for that uses redhat do so because they think paying will prevent them from working. As if, sudenly, running a nearly 10y-old code was no longer stupid, because you paid for it.

[fusslo]

> As if, suddenly, running a nearly 10y-old code was no longer stupid, because you paid for it.

I love this

[bonzini]

Of course it is stupid, the question is whether you have an alternative that isn't stupid and respects all the regulation/certification requirements.

[sqeaky]

I wish the places I worked made such principled decisions.

Some places did, but not most. In my 2 decades of contracting I have seen plenty of shops with a real fear of upgrading and no plan for modernizing. They are trapped in decades old tech and prefer it that way for no discernible reason. Worse, they often have no recovery plan if there is a problem. There is a huge amount of maintaining the status quo and trying not to make waves.

For some of these projects a team of like dozen devs could recreate the core product in some new tech in less than a year with the right institutional knowledge. But they don't for a myriad of excuses and reasons.

[bonzini]

To be fair, if they couldn't make the decision to use a non-paid distro, would you trust them to be able to manage the updates, the ABI compatibility breakages, and so on once every year or two?

[JackSlateur]

Of course not

But again, paying for the distribution does not free you from the sysadmin duties

Even worse: because of the long "supported" duration, the common mindset is "fire and forget". After all, why would we care ? That stuff will be "supported" for 10 years, we'll be long gone by then. And when you have high turn-over rate, you hit the champion's title : every thing is legacy, nothing is managed, every thing is crap

[JackSlateur]

Said compagnies have no regulations nor certifications requirements.

[worthless-trash]

I work in the kernel maintenance group, the "10 year old code" is having select important and critical flaws applied.

If you think about it, all maintained projects of old code has this same mechanism, just has more frequent updates.

How does the age metric now work once you know this ?

[qalmakka]

I understand the business logic behind that. The point is, maybe they should consider paying the upstream developers to backport the stuff themselves instead of dabbling with C code they somewhat understand?

[sqeaky]

C isn't magic, plenty of people understand it and lots of these projects move quite slow. That these things CVEs on ssh are so rare shows how well this process normally works. These past couple of weeks have had 3(?) ssh vulnerabilities? We often go years with one, and not all are a result of packaging some come from upstream.

Any new process needs to not just fix this problem, but also all or at least most of the problems that the existing processes fixes.

[gruturo]

Tracing thousands of developers across the planet and drafting contracts in hundreds of jurisdictions, including some where you don't even have a branch office or any kind of legal presence? Ugh. And what if one's from an embargoed country? What if a primadonna asks for a million a day, or half of them don't deliver in time, go on holiday, win the lottery, fall in love, get into a dispute, refuse to work with you, don't have access to all the architectures for comprehensive testing, lose interest, change employer (and can't work with you anymore), or sell to some dodgy entity preparing the next sBoM attack.

....better to pay your own people. Hire them if they're available, sure, otherwise task an engineer with this.

[rlpb]

Distributions patch to get consistent and integrated behaviour across the platform, including new features that require implementation into multiple places to be even minimally useful, and ports to newer APIs to make everything work against a single version of each library so that they do not conflict.

Upstreams generally don't do this until prompted, and sometimes resist until the path is proven and becomes best practice because distributions pushed it.

This process is mostly invisible to you because distributions have been successful at getting the changes needed for sane and consistent behaviour embedded into tools and expectations by default. All you see are the patches that are in flight or didn't make it.

If you want a distribution that does only minimal patching then there are distributions for that. The fact that the major distributions do patch speaks volumes about which approach results in a better experience for users.

[Diederich]

Do you think there is a reason that some distros go through all of this additional trouble?